Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify dotTrace diagnoser, dedupe common code #2558

Conversation

martinothamar
Copy link
Contributor

@martinothamar martinothamar commented Apr 12, 2024

Similar approach to #2549 for simplifying DotTraceDiagnoser.

Also deduped some code by creating a shared project (using <Compile Include="..." /> to avoid another package).
Pulled this code into JetBrains folder so that the projects are ordered next to eachother in file explorers.
Made sure to update build script and references to include the new folder.

Other options:

  • Just not dedupe
  • Keep the common code in one of the projects and just include from there
  • ?

@timcassell
Copy link
Collaborator

Could you use shared project for this?

image

@martinothamar
Copy link
Contributor Author

TIL, did not know that existed 😄

I wanted to test that out now but I'm not sure if it's possible to create that project type for me since I'm working on Linux atm. .NET SDK, Rider and VSCode C# DevKit all seem to be missing support for creating this project type.

Reading up on this issue: dotnet/sdk#2511
There seems to be some complaints about the UX of it, but that it is fully usable. Some people suggest Microsoft.Build.NoTargets, while the "official" recommendation seems to be using a folder + globbing includes? I thought having a plain folder to contain the files would make intellisense/tooling/IDE experience worse but testing that out now its completely fine and everything works as expected. So personally I think the plain folder approach seems to be nice enough and lightweight. I pushed a commit now to do that

I could try out shared projects, but I would have to hand-code it unless someone on a Windows PC could scaffold it for me. What do you think?

@timcassell
Copy link
Collaborator

Ah, I didn't realize that was legacy project type. I think just using the folder approach is good.

{
public class Progress : IProgress<double>

internal sealed class Progress : IProgress<double>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was public before. Is it ok to remove it from public API? @AndreyAkinshin

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, I forgot to mention that. I figured since it's not used by any configuration or anything it makes sense to not expose it? Users could have referenced it for some reason, but not because of any interaction with BenchmarkDotNet AFAICT.

If we keep it public I probably have to do something about the namespace, so that both packages don't expose the same type in the same namespace, unless that's not a big deal since we don't expect anyone to import BenchmarkDotNet.JetBrains regardless of which package is used?

@AndreyAkinshin
Copy link
Member

@martinothamar thanks for the PR! Indeed, it makes sense to unify dotTrace/dotMemory diagnosers and eliminate code duplication. However, the presented approach inherits the disadvantages of the poor design of the original diagnosers. Both were born as prototypes. Now, it's time to refactor them. I have come up with a better solution for this problem, see #2627.

@martinothamar martinothamar deleted the chore/simplify-dottrace-and-share-code branch August 28, 2024 06:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants